Fix primary.idx corruption after delete mutation #9048
Conversation
alesapin
added
pr-bugfix
|
Unit tests — Segmentation fault -- already fixed on master, not related to changes. |
|
Did you find out why the order of rows changes? Theoretically, when reading sequentially in a single thread, it should be the same. |
| else | ||
| key_expr = metadata.order_by_ast; | ||
|
|
||
| bool empty = false; |
There was a problem hiding this comment.
What does this check for, something like order by tuple()? Can we just remove this check and pass the order by always, or does it break something? Btw I found that order by tuple() doesn't seem to work, because tuple requires at least one argument, but order by 1 does.
There was a problem hiding this comment.
Yes we cannot order by tuple() and in this case we don't need order by at all.
Still not, but I'll try to find the next week. Anyway, when we use |
Fix primary.idx corruption after delete mutation
|
Backport conflict in 19.17 |
Fix primary.idx corruption after delete mutation
This reverts commit 5be678f.
I hereby agree to the terms of the CLA available at: https://yandex.ru/legal/cla/?lang=en
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
Fix bug in
ALTER DELETEmutations which leads to index corruption. This fixes #9019 and #8982. Additionally fix extremely rare race conditions inReplicatedMergeTreeALTERqueries.